Invalidate the whole result cache when a changed package registers a container class - #6088
Conversation
4812aa5 to
cc5ce71
Compare
ondrejmirtes
left a comment
ondrejmirtes
left a comment
There was a problem hiding this comment.
Please add another E2E project to test. One that doesn't include extension's neon file via includes but registers an extension via phpstan/extension-installer.
33306c0 to
00d5e6d
Compare
|
Added |
staabm
left a comment
staabm
left a comment
There was a problem hiding this comment.
I verified the e2e tests locally and they work as expected. I am not 100% into the impl details of ResultCacheManager.
@ondrejmirtes please give it a final go
…container class The package-granular invalidation only re-seeds files that depend on a changed Composer package through code references. A package that registers a rule or extension in the PHPStan container (larastan and similar) is not referenced by the analysed code, yet its code can change the analysis of every file, so the granular re-seed left the cache serving stale results after such a package was updated. Before the package-granular invalidation any composerInstalled change forced a full re-analysis, which happened to cover this. Detect it: when a changed package owns a class registered in the container (ProjectConfigHelper::getServiceClassNames resolved to a package via PackageDependencyResolver::resolvePackage), re-analyse everything instead of only the file-granular dependents. Packages that contribute nothing to the container keep the granular path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
00d5e6d to
36a171d
Compare
|
looked at it again, and I think it is good to go. thanks @SanderMuller |
3 participants
Follow-up to #6086 and a discussion with @staabm. The package-granular result-cache invalidation from #5933 does not invalidate the cache when a Composer package that registers a class in the PHPStan container (a rule or extension, e.g. larastan) is updated.
getChangedComposerPackages()reports the changed package, and the incremental loop then re-seeds only the files that depend on it through code references. An extension package is not referenced by the analysed code, so zero files are re-seeded and the previous results are served from the cache even though a rule changed.projectExtensionFilesdoes not cover this either, becausegetProjectExtensionFiles()skips service classes whose file is undervendor/with no tracked dependencies.This is a regression from #5933. Before it, any
composerInstalled/composerLockschange forced a full re-analysis, which happened to catch this.The fix: when a changed package owns a class registered in the container (
ProjectConfigHelper::getServiceClassNames()resolved to a package viaPackageDependencyResolver::resolvePackage()), re-analyse everything instead of only the file-granular dependents. Packages that contribute nothing to the container keep the granular path.Added an e2e test (
result-cache-extension-update): a package ships a rule through itsextension.neon, the package is then updated (rule body changed and itsreferenceinvendor/composer/installed.phpbumped, ascomposer updatewould), and the run must re-analyse everything and report the new rule output. It fails before this change (granular re-seed, 0 files, stale output) and passes after. The existingresult-cache-package-updatee2e keeps asserting that a normal package update stays file-granular, so this does not over-invalidate.Closes phpstan/phpstan#14986